home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4440 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: why not add getch() to the std C RTL?
  5. Date: 4 Feb 1996 09:16:25 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4f2pl9INNmmm@keats.ugrad.cs.ubc.ca>
  8. References: <DM85L8.5Jn@emr1.emr.ca> <bnelsonDM887t.LDI@netcom.com>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <bnelsonDM887t.LDI@netcom.com>,
  12. Bob Nelson <bnelson@netcom.com> wrote:
  13. >On Sun, 4 Feb 1996 00:05:32 GMT, John Grant wrote:
  14. >
  15. >> There are *many* people who want to do the following in their C programs:
  16. >> - read a single unbuffered keystroke (getch() in DOS, ioctl in unix...)
  17. > 
  18. >> The usual response is "not standard C, o/s-specific" etc.
  19. >
  20. >I'll just quote the following from "Expert C Programming" by Peter van
  21. >der Linden (ISBN 0-13-177429-8) and offer no comments of my own, other
  22. >than some emphasis added.  Instead, it'll be interesting to see how
  23. >participants in comp.lang.c respond to what PvdL thinks (especially in
  24. >the context of your posting). Here's the paragraph from page 213:
  25. >
  26. >"People often wonder why ANSI C didn't define a standard function to
  27. >get a character if a key has been pressed. Without a standard
  28. >function, every system has a different method and program portability
  29. >is lost.  The argument against providing kbhit() as part of the
  30. >standard is that *it is mostly useful for GAMES software* and there
  31. >are many other terminal I/O features that are not standardized. In
  32. >addition, you don't want to promise a standard library function *that
  33. >SOME OS's will find difficult to provide.* The argument for providing
  34. >it is that it is mostly useful for games software and that games
  35. >writers don't need the myriad of other terminal I/O features that
  36. >could be standardized. Whichever view you hold, it's true the XJ311
  37. >missed an opportunity to reinforce C as the language of choice for a
  38. >generation of programmers writings games on UNIX."
  39. >
  40. >Comments? 
  41.  
  42. More comments:
  43.  
  44. Suppose kbhit() were part of the standard. That's not enough to encourage game
  45. programming. You also want, even for text-based games, full-screen control.
  46. Implementing kbhit() is trivial compared to terminal control. Including
  47. curses-like functionality in the standard would bloat it immensely with
  48. functions that are irrelevant for most people.
  49.  
  50. This lack did not stop that "generation of game programmers". Instead, they
  51. poured back some brewski's and developed the BSD curses library which, by the
  52. mid 80's, AT&T snatched to develop a more powerful version for AT&T UNIX.
  53.  
  54. Furthermore, kbhit() is obsoleted with the advent of graphics, which is what
  55. game programmers are ultimately interested in. Is kbhit() still used under
  56. Microsoft Windows? X11 doesn't use it; an X program receives events, some of
  57. which can be keypress and keyrelease events---which gives you far more general
  58. semantics that are akin to the PC's "scan codes". An X11 game can sense that a
  59. key is held down independently of other keys, in a standard manner that works
  60. on all X terminals.
  61.  
  62. (Check out the controls for xpilots---idependent firing, rotation, thrust and
  63. shields and other commands).
  64.  
  65. This is not something you can do having only the functionality of kbhit().
  66. In fact, it's not even possible with ordinary terminal I/O, unless you have a
  67. special terminal that can pass you press/release codes.
  68. -- 
  69.  
  70.